Skip to main content

ANALYSIS: MAC Inventory


Kibana Dashboard: [INVENTORY] MACs


What is this baseline?​

The associated Kibana dashboard represents the baseline inventory of MAC addresses observed within the DAL.

  • A MAC entry consists of:
    • host.mac
    • Zero or more associated host.ip values
    • Zero or more associated host.hostname values
  • Each row answers:

    "Was this MAC address observed in the baseline inventory?"

  • This is not a NAC, switch CAM table, or asset tracking system:
    • No notion of physical port or location
    • No guarantee the device is currently connected
    • No assurance the MAC represents a unique device
  • A single corroborated observation is enough to add a MAC to the baseline.
How the baseline is built
  • Entries are deduplicated by MAC
  • MACs are added when correlated to a DAL IP
  • MACs may be associated with one or more IPs and/or hostnames
  • @timestamp reflects when the MAC was last observed and written into the baseline

Data Prerequisites​

note

If any of these are missing or incorrect, the baseline is unreliable.

1. DAL / HOME_NET must be correct​

  • Derived from Zeek and/or Suricata HOME_NET
  • Used to scope which IPs (and therefore MACs) are considered internal
  • Incorrect DAL β†’ missing internal devices or inclusion of irrelevant MACs

2. Required telemetry sources (at least one)​

  • Zeek (conn, dhcp)
  • Winlogbeat
  • Auditbeat
  • Metasponse
    • ARP Cache Collector
    • DHCP Collector
    • 262 - [πŸ”₯Volatile Info] ARP Cache

NOTE: MAC discovery is highly dependent on L2/L3 visibility.
Environments with limited DHCP or Zeek coverage will have partial MAC inventories.


Basic Analysis Workflow​

1. Baseline sanity check​

Validate expected device population:

  • MAC count roughly aligns with known host count
  • Known infrastructure and endpoints are represented
  • No obvious placeholder or junk MACs (e.g., broadcast-only artifacts)

Unexpected gaps usually indicate missing telemetry, not stealth.


2. Long-tail analysis (primary value)​

Focus on unusual or unaccounted MACs

  • MACs with no hostname
  • MACs associated with multiple IPs unexpectedly
  • MACs that appear late in baseline establishment

Key questions

  • Virtual interface or container?
  • Infrastructure device (switch, router, sensor)?
  • Temporary or mission-support system?
  • Unauthorized or rogue device?

Validate against:

  • Network diagrams
  • Known infrastructure inventories
  • Admin confirmation if required

3. IP and hostname correlation review​

Multiple IPs per MAC

  • Normal for DHCP churn
  • Expected for virtualization or mobility
  • Suspicious if spanning security zones or subnets

Multiple hostnames per MAC

  • Common during reimaging or renaming
  • Rarely benign if simultaneous

Correlation anomalies indicate ambiguity, not automatic compromise.


4. Export for reporting and diffing​

note

Reporting and documentation requirements are determined by the Mission Element Lead/Crew Lead

Common exports

  • Full Inventory table (CSV)
  • MAC ↔ IP ↔ hostname mapping

NOTE: These exports represent the declared MAC baseline for the mission period.


5. Enable baseline deviation detection rule​

caution

Enabling too early guarantees noise - it will alert on ALL new inventory additions after enablement.

tip

Detection rules can be managed in Kibana under Security β†’ Rules

Rule: [262][Inventory] New MAC added to baseline​

  • Detection logic:

    Alert when a new MAC address within the DAL is added to the baseline inventory

  • Only enable after:
    • Baseline window is complete
    • Expected devices are observed
    • Long-tail MAC review is finished
  • Ongoing alert tuning:
    • Whitelist known late-arriving devices
    • Suppress ephemeral or virtual interfaces
    • Validate whether the MAC represents a truly new device

This rule is intended to catch:

  • Rogue physical devices
  • Unauthorized wireless or wired connections